BBS in a Box 12/BBS in a box XII-2.iso/Files II/Prog/M/MacWT 0.04.sit/WT Docs/README

Text File | 1994-05-18 | 8.9 KB | 219 lines

wt - a 3D game engine

Copyright (C) 1994 by Chris Laurel

Please see the LICENSE file for further details.  You may not distribute
this project without this file (README) and the LICENSE file included.

---------------------------------------------------------------------------

This is still a preliminary version of my 3D game engine, wt.

* In the proud tradition of cp, mv, rm, as, and cc, now there is 'wt'
  wt (never capitalized) stands for "what's that?"

* This is not by any means a complete game.  It is just a demo of my
  graphics engine.  I'd never name a game wt.

* wt is portable software.  See the section on porting at the end of this
  README for information on what to change in order to port to another
  platform.

* Features:
    * Easy to edit world file.  Just haul out your favorite text editor
      and modify 'castle.world'  Or create your own .world file from
      scratch.  Whee.  Just don't get carried away because the world
      file format will be changing before the next release.
    * No BSP trees were killed to make this program.  Sorry . . . it's
      late.  BSP trees are elegant and fast *if* your environment is
      static.  I eventually want walls in wt that move and change shape.
      However, if I can't kill a bug having to do with walls perpendicular
      to the view plane, I may have to resort to a BSP tree for determining
      wall visibility (or if my current algorithm is too slow for worlds
      with a large number of walls.)
    * Variable texture map size.  Texture maps for walls can be any
      width you like, but the height must be either 64 or 128.  Floor
      textures must be either 64x64 or 128x128.  The main reason why
      arbitrary powers of two aren't supported has to do with the fact that
          Intels x86 chips don't have enough registers for my innermost loops.
    * Texture scaling for walls.  The walls have an x scale factor and
      a y scale factor.  It might be more properly called 'frequency,'
      since the smaller the parameter, the bigger the texture map will
      appear.  Supporting the scaling factors requires a couple of extra
      multiplies in the wall drawing function.


* Running the demo (this applies to the Linux version only):

    * For xwt, just type 'xwt castle.world'  The keys are:
        forward - up arrow
        backward - down arrow
        turn left - left arrow
        turn right - right arrow
        strafe - slash
        run - shift
        jump - space

    * To run wt, you need to be root (or make it setuid root first.)
        It sucks to have to run a binary you grabbed off the net as
            root, but as far as I know, that's the way it has to be with
        svgalib base programs.

        As root, type 'wt castle.world'  The keys:

        forward - e
        backward - x
        turn left - s
        turn right - d
        strafe left - a
        strafe right - f
        jump - space


* Responses

    * I received a lot of e-mail from people about the binary-only
      version 0.01 of wt.  Thanks for all the interest, and I apologize
      to anyone to whom I did not respond.  I've been frying my brain
      on wt.

    * While wt does look similar in many respects to DOOM, it is not
      based on any DOOM source code, and I have no connection with Id
      software other than being a customer.

    * The most frequently asked question was about the texture file
      format.  As you can now tell by looking at texture.[ch], it
      is my own format.  There's no reason for this beyond the fact
      that I wanted something for a quick prototyping of the engine,
      and I didn't have any graphic file format specs sitting around.
      I'm open to suggestions about texture file format.

    * I will add mouse support for the X11 and svgalib versions.  I also
      want to support the Linux keyboard better by setting it to
      RAW mode.

    * Your X server needs to support the MIT shared memory extension
      in order for wt to run.  Also, it only currently supports an
      8-bit pseudo color visual.  I just haven't had a chance to perfect
      the X code.

    * I will eventually design a world editor.  It will run under X and
      be based on Tcl/Tk.

    * Pitch and roll will not be supported.  It's a fundamental constraint
      of the engine design.

    * Weird things will happen when you jump above the tops of buildings
      or though the ceiling.  You cannot see the tops of buildings--this
      is another design limitation.

    * Resizing the view window . . . this does need to be supported.  The
      reason why it is not currently supported again has to do with the
      limited register set of the x86 chips.  I wanted to keep all my
          variables in registers in the innermost loop, but they would not
      all fit.  So, I made the view width an immediate constant . . . if
      I can coax gcc to let me use the ebp register, I'll use that to
      hold the width.  Or I could just deal with the (probably minor)
      speed degradation I'd get by reading it from memory.


* Room for improvement

    * Better texture file format.  There's some unnecessary information
      in the texture files now which is left over from a previous 3D
      project.

    * Optimizations.  There are some obvious ones that I have not gotten
      around to implementing yet.  In particular, the multiplies in
      calc_wall_heights can be avoided.  I think that the floors code
      can be sped up also.  If you know of any improvements to the
      assembly loops in slice.c, *tell me*.  I'm not an Intel assembly
      language guru or anything.

    * Code cleanup.  The core of wt is still in development, so some of
      the code surrounding the renderer is hacky test-the-engine stuff.
      Once wt starts developing into a real game, much of the code
      will be reorganized.  wt.c will change completely.


* 'Port away!'

    * wt now supports both big and little endian machines.  The only
      endianness dependent part of the code was in texture.c.  If you
      have a big endian machine (pretty much anything but an Intel system)
      you may need to edit the makefile and add -DBIG_ENDIAN to CFLAGS.
      However, my system already has an endian #define, so you may
      not need to do anything.

    * There are three types of #define's used to block off non-portable
      sections of the code.  ARCH_i86 surrounds the couple assembly
      routines in the wt source.  I also surround these with an
      #ifdef __GNUC__ because the inline assembly code syntax in
      gcc is different than for other x86 compilers I've seen.  (Anyone
          considering doing an DOS or Windows port take note:  the GNU
      assembler uses AT&T syntax, which has the reverse operand order
      of Intel syntax.)  Finally, there is a #define to identify
      the graphics system.

    * Substitute C routines exist for assembly language functions.
      On a RISC system with a good compiler, I figure you shouldn't need
      to recode them in assembly language.  The C functions *should* work.
      I have not tested them in a while, but they were used extensively
      before I rewrote them in assembly.

    * Before attempting to compile on a non-UNIX system, #define PROFILE
      to be zero in render.c.

    * If you've got a non-Intel system with X11 (or an Intel system
          with X11 which does not have gcc), then you should be able to
      compile wt successfully by just not defining ARCH_i86 in the
      Makefile.

    * If you're not running X11, then you'll need to write your own
      graphics and input routines and add a #define for your graphics
      system.  Check out linuxvga.c and x11graphics.c for sample
      graphics implementations.  All you need is an initialization
      function, a cleanup function, and something to blast a framebuffer
      the screen--memcpy, CopyBits or whatever . . .

    * The input system hooks are in input.c.  For sample input routines,
      look in linux-console.c and x11input.c.  Mac and Windows people:
      x11input.c should give you a good idea about how to tie an
      event handler into wt.

    * Send me your ports and I'll include them in the next wt distribution!
      This goes for other improvements to wt, too.  Although I love
      hearing ideas, I'm *not* building a game yet.  I'm just interested
      in getting the engine working cleanly and quickly on as many
      platforms as possible.

    * I'm especially interested in reports about how fast wt will run
      on different platforms (wtStones?)  If you do a port, talk to me
      about speed, especially if you have a PowerMac or Alpha system.
      If you port it to a 286, I'm interested but I might laugh.


* Future directions:

    * I'd like to see wt become a multi-platform client for an
      Internet wide MUD type game.  Or a perhaps a net-wide arcade
      game like Xpilot.  I've got a lot of other more innovative ideas
      but I'd better get the engine done before I start spouting about
      them.

* CREDITS

    Dan Egnor ([e-mail]) - submitted the first set of
         endian fixes.
    Dave Thomas ([e-mail]) - wrote up an Imakefile

* Me:

    send any comments, ideas, bug reports, etc. to:

    Chris Laurel
    home: [e-mail]
    work: [e-mail]
    snailmail: 5700 W Lake St, #208
                   St. Louis Park, MN  55416